Comunicación síncrona o asíncrona
Símil:
Comunicación síncrona ? llamada telefónica
Comunicación asíncrona ? correo postal
La comunicación síncrona es en principio más sencilla de implementar
Podemos emular comunicación síncrona usando primitivas de comunicación asíncrona. P.ej. usando SEND y REPLY.
Podemos emular comunicación asíncrona usando primitivas de comunicación síncrona. Símil: contestador automático
Repercusiones de la comunicación asíncrona
El emisor puede enviar varios mensajes:
NECESIDAD de disponer de búferes
¿Cuándo sabe el emisor que su mensaje ha llegado/se ha atendido?
conveniencia de operaciones de “acuse de recibo” o de respuesta(send ? receive ? send_reply ? receive_reply)
Llamadas bloqueantes / no bloqueantes
Las operaciones de envío y recepción pueden estar definidas como bloqueantes o no bloqueantes
Un envío/recepción con bloqueo es un ejemplo de comunicación síncrona
Un envío/recepción sin bloqueo es un ejemplo de comunicación asíncrona
Identificación
Comunicación directa
Cada proceso que desea comunicarse debe nombrar explícitamente el destinatario o el remitente de la comunicación
enviar(P, mensaje)
Enviar un mensaje al proceso P
recibir(Q, mensaje)
Recibir un mensaje del proceso Q
Identificación
Comunicación indirecta
Con la comunicación indirecta, los mensajes se envían a, y se reciben de, buzones (también llamados puertos)
enviar(A, mensaje)
Enviar un mensaje al buzón A
recibir(A, mensaje)
Recibir un mensaje del buzón A
Comunicación indirecta
P1, P2, P3 comparten un buzón A. P1 envía un mensaje a A, y P2 y P3 ejecutan cada uno un recibir de A. ¿Qué proceso recibirá el mensaje que envió P1?
Un buzón puede ser propiedad de un proceso o del sistema
Identificación
Comunicación simétrica
Los procesos tanto receptor como emisor necesitan nombrar al otro para comunicarse
Comunicación asimétrica
Sólo el emisor nombra al destinatario. Particularmente útil para cliente/servidor
Otra forma más flexible: bulletin boards (tablones) => nadie nombra a nadie
Ejemplos
Comunicación directa simétrica
Enviar(P,mensaje)/Recibir(Q,mensaje)
Comunicación directa asimétrica
Enviar(P,mensaje)/Recibir(mensaje)
Enviar(P,mensaje)/Recibir(id,mensaje)
Características del canal (1)
Punto a punto, multipunto
Unidireccional, bidireccional
Capacidad del canal
cero
limitada
infinita (teórico)
Características del canal(2)
Mensajes:
Tamaño fijo o variable
Canales con tipo o sin tipo
Paso por copia o por referencia (¡cuidado!)
Características del canal de comunicación: ejemplos
Comunicación directa
Se establece automáticamente
Un canal se asocia a exactamente dos procesos
Entre cada par de procesos sólo existe un canal
El enlace puede ser unidireccional, pero suele ser bidireccional
Características del canal de comunicación: ejemplos
Comunicación indirecta
Se establece un canal entre un par de procesos sólo si tienen un buzón compartido
Un canal puede estar asociado a más de dos procesos
Entre cada par de procesos en comunicación puede haber varios enlaces distintos, cada uno de los cuales corresponderá a un buzón
Los enlaces pueden ser unidireccionales o bidireccionales
Elección de mensajes
Supongamos un proceso servidor que es capaz de recibir peticiones de varios canales.
Queremos que el proceso quede bloqueado hasta que alguna petición llegue.
¿cómo lo resolvemos?
solución: espera selectiva (select), espera no determinista (ALT de occam), “select” de UNIX, etc.
Condiciones de error
1 máquina => los mensajes se implementan (generalmente) en memoria compartida
Fallo => falla todo el sistema
Entornos distribuidos => procesos residen en diferentes máquinas
Los mensajes se transfieren por líneas de comunicación
La probabilidad de que ocurra un error durante la comunicación y el procesamiento es mucho mayor que en un entorno de una sola máquina
El fallo de un enlace no causa necesariamente el fallo de todo el sistema
Condiciones de error
Cuando ocurre un fallo en un sistema, sea centralizado o distribuido, el sistema debe intentar recuperarse del error
Algunas situaciones de error:
El emisor o el receptor podría terminar antes de que se procese un mensaje
P espera un mensaje de Q (proceso terminado)
P envía un mensaje a Q (proceso terminado)
Condiciones de error
Mensajes perdidos
Fallo hardware o de la línea de comunicación
Tres métodos para enfrentar este suceso en función de quien asume la responsabilidad de detectar el fallo:
SO
Emisor
SO/Emisor
Condiciones de error
No siempre es necesario detectar los mensajes perdidos => protocolos de red que garantizan la confiabilidad
¿Cómo detectar la pérdida de mensajes?
El método de detección más común consiste en emplear tiempos límite o plazos
Condiciones de error
Mensajes alterados
es común el uso de códigos de verificación de errores (paridad, etc…)
Invocación remota: el modelo de Ada
Características del Rendezvous de Ada
Esquema de comunicación síncrono (rendezvous), sin búferes
Esquema de comunicación asimétrico (el emisor necesita conocer la identidad del destino pero no ocurre lo mismo con receptor)
Durante la cita, el flujo de datos es bidireccional
Llamada a Procedimiento Remoto (RPC)
Motivación:
Aprovechar el paralelismo potencial existente en un sistema distribuido
¿ Cómo ?
Posibilitando que un proceso llame a un procedimiento que se ejecutará en otro procesador
Invocación remota vs RPC’s
La invocación remota es una construcción de los lenguajes concurrentes
La RPC es una técnica para permitir llamadas a procedimientos en entornos distribuidos
La palabra “remoto” tiene significados diferentes en ambos casos:
Invocación remota: “otro proceso”
RPC: “otro procesador”
Invocación remota vs RPC’s
El punto de entrada llamado durante una invocación remota sólo se ejecutará cuando su propietario lo permita
El procedimiento llamado durante una RPC se puede ejecutar de inmediato
El punto de entrada llamado durante una invocación remota es ejecutado por el proceso propietario de dicho punto de entrada
El procedimiento llamado durante una RPC se ejecuta en nombre del proceso llamador por un proceso subordinado creado por el entorno de ejecución
Invocación remota vs RPC’s
El proceso llamador y el punto de entrada llamado durante una invocación remota se pueden ejecutar en el mismo procesador. Esto no tiene sentido en el caso de una RPC
Dificultades implementación RPC’s
Paso de parámetros
Valor
Referencia: ¡más complejo!
Los formatos internos de los datos pueden ser muy diferentes en redes de máquinas heterogéneas
Requerirían conversaciones complejas y un considerable trabajo adicional
Fallos en la transmisión
Bibliografía
Principles of Concurrent and Distributed Programming
M. Ben-Ari. Prentice Hall, 1990
Capítulo 7
Sistemas Operativos
A. Silberschatz, P. Galvin. Addison Wesley Longman, 1999
Capítulo 4.6
Concurrent systems
Jean Bacon, Addison-Wesley, 1998
Capítulos 13-15
 Página anterior | Volver al principio del trabajo | Página siguiente  |